REMARKS 



Claim Rejections Under 35 U.S.C. Section 112 

Examiner rejected claims 2-6 as being indefinite for failing to particularly point out and 
distinctly claim the subject matter which applicant regards as the invention. Pursuant to 
Examiner's recommendation, Applicant amended claims 2-6 to recite the limitation "receiver", 
which has an antecedent basis in claim 1, instead of "system", which does not have an antecedent 
basis in claim 1 . 

Claim Rejections Under 35 U.S.C Section 102 

Examiner rejected claims 1-14 as being anticipated by U.S. Patent No. 6,304,551 
(Ramamurthy). In doing so, Examiner has taken the position that Ramamurthy discloses each of 
the limitations in the pending claims. Below, Applicant addresses Examiner's position and the 
bases underlying Applicant's respectful disagreement with Examiner's interpretation of the 
Ramamurthy reference. 

As a threshold matter, underlying Examiner's interpretation of the Ramamurthy reference 
is an apparent confusion over a) how the cell stream traffic is characterized and b) precisely what 
is being subject to "real-time estimation". Ramamurthy operates by receiving a cell stream from 
a source, characterizing the cell stream, and, based on that characterization, developing a set of 
usage parameter control (UPC) values. The UPC values are derived by minimizing a cost 
function subject to predetermined constraints. 

In the first step of receiving and characterizing a cell stream, Ramamurthy discloses the 
use of peak and mean rates of the cell stream transfer to calculate optimum UPC values by 
(Col.7:24-52): 

(a) offering the traffic stream to a bank of N constant service rate queues with spaced 
rates that are spaced between an estimated mean rate and an estimated peak rate where the 
spaced rates are candidates for sustainable rates (these are not delays; rather these are merely the 
estimated mean and peak rates of transmission); 
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(b) approximating a tail waiting time distribution for each of the queues using a constant 
service rate and one of the candidate sustainable rates (again, this is not a transmission delay; 
rather, this is merely the waiting time in the traffic shaper); and 

(c) estimating parameters from the equations associated with the above steps. 

Once the cell stream is characterized using the mean and peak transmission rates and the 
associated variables are calculated, the UPC values are obtained via a mapping step. That 
mapping step: 

(a) computes, for each of the candidate sustainable rates used in the characterizing step, a 
corresponding value for a smallest sustainable bucket size such that a sustainable rate leaky 
bucket satisfies a constraint which bounds one of a cell violation probability and a mean shaping 
delay (again this is a delay imposed by the traffic shaper, not created by virtue of transmission 
from the source to the traffic shaper); 

(b) computing, for each of the candidate sustainable rates used in the characterizing step, 
a corresponding value of the cost function that determines cost to the network; 

(c) selecting, among the candidate sustainable rates, an optimal sustainable rate that 
minimizes the cost function; and 

(d) choosing new UPC values that include the peak rate, the optimal sustainable rate, and 
the sustainable bucket size. 

Ramamurthy is not attempting to account for, or calculate variables based upon, a delay 
experienced by data packets in transmission. On the contrary, it is doing precisely the opposite — 
calculating what delay to impose on data in order to achieve specific transmission rates and abide 
by particular UPC values. The "real-time estimation" is not directed toward the real-time 
estimation of delays experienced by data packets and the real-time accounting for such delays. 
Rather, the Ramamurthy system has the ability to characterize traffic streams and, as they change 
(i.e. transmission rates change), perform a real-time estimation of new traffic shaping parameters 
and negotiate those parameters with a network provider. Again, the real-time estimation has no 
relationship with the measurement or calculation of delays experienced by data packets. 

Examiners' confusion is highlighted by his frequent reference to certain portions of 
Ramamurthy that allegedly disclose the calculation and use of mean cell delays or delay jitter. 
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However, those sections merely support Applicant's argument — that Ramamurthy's invention is 
completely different from Applicant's. For example, Figures 6 and 7 do not demonstrate the use 
of mean cell delays in a manner similar to Applicant's invention. On the contrary, those figures 
are merely used to demonstrate how close Ramamurthy's theoretical calculations approximate 
real-life mean delays which are imposed upon the cell stream by the traffic shaper. None of the 
mean cell delay data is disclosed as being used by the Ramamurthy system to estimate playout 
times and, by definition, they can't be. These mean cell delays are created by the traffic shaping 
system and, therefore, can't be simultaneously used by the system to determine how to shape the 
incoming traffic. See Col. 15:27-41. 

Similarly, Ramamurthy discloses a theoretical calculation of delay jitter in order to 
demonstrate where, in the range of operational service rates, one should operate. After 
Ramamurthy engages in an analysis of the appropriate modeling of delay jitter, he notes that 
"delay should be more highly variable as the service rate u approaches the mean rate. This 
suggests that, in general, the region of rates near the mean should be avoided." Col. 12: 1-20. 
Ramamurthy is providing instructions on what service rate should be selected in order to 
minimize delay jitter, which is in line with the fact that his system shapes the traffic, and is not 
subjected to it. 

Finally, nowhere does Ramamurthy disclose the use of data packet delay histograms, 
mean delay data, or variances thereof to calculate the bucket size. Examiner's insistence that the 
specification somehow inherently discloses the measurement of, and use of, the actual delay 
experienced by data packets in transmission from a transmitter to a receiver is completely at odds 
with the express protocol for characterizing the cell stream traffic and calculation of the UPC 
values, none of which includes, or is dependent upon, actual packet delays of any kind. The 
modeling of a cell stream using a peak or mean transfer rate is completely different from 
measuring delays experienced by packets during transmission and using those delays to smooth 
jitter. 

Moreover, it would make no sense for Ramamurthy to be concerned with such delays. 
His system focused on how to impose delays on traffic in order to have them meet certain UPC 
performance values. To determine those delays, he first characterizes the traffic stream based on 
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their transmission rates, not packet data delays, which are often outside the control of the system. 
See, e.g., Col. 14:1 1-28 and Col.5:60-Col.6:5. Using that characterization, the Ramamurthy 
system performs a real-time estimation and negotiation of UPC values which are used to 
proactively shape a stream in order to achieve certain QoS objectives, as constrained by certain 
cost parameters. 

Consequently, Examiner's assertions that Ramamurthy discloses the present invention are 
simply incorrect. Taking a representative set of limitations present in the pending claims: 

• A counter for determining delays experienced by data packets in transmission 
from a transmitter to a receiver. Ramamurthy does not disclose it and does not 
inherently need it. It characterizes traffic based on mean and peak transmission 
rates. It need not know or calculate the delays experienced by data packets in 
transmission from the source to the traffic shaper. Nowhere does Ramamurthy 
disclose the need to include transmission delays in the characterization of the cell 
stream traffic or calculation of the UPC values. 

• A delay estimator adapted to estimate data indicative of an adaptive packet delay 
histogram, having a mean, wherein the data indicative of the packet delay 
histogram is a function of the delays experienced by data packets in transmission 
from the transmitter to the receiver and the number of data packets received at the 
receiver. Ramamurthy does not disclose it and does not inherently need it. It 
characterizes traffic based on mean and peak transmission rates. The 
determination of the UPC values does not include or depend upon the delays 
experienced by data packets in transmission from the source to the traffic shaper 
and, therefore, no adaptive packet delay histogram is used in the characterization 
of the cell stream traffic or calculation of the UPC values. 

• A playout delay evaluator in data communication with the delay estimator and 
adapted to receive data from the delay estimator, wherein the playout delay 
evaluator calculates a playout time, and wherein the calculation of the playout 
time utilizes the mean and a first variance derived from a portion of data 
indicative of the packet delay histogram. While Ramamurthy' s traffic shaper does 
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evaluate a playout delay and impose some delay on the playout, it does not do so 
based upon a mean or first variance derived from a portion of the packet delay 
histogram, as discussed above. 

Measuring delays experienced by data packets in transmission from said 
transmitter to said receiver. Ramamurthy does not disclose it and does not 
inherently do it. It characterizes traffic based on mean and peak transmission 
rates. It need not know or calculate the delays experienced by data packets in 
transmission from the source to the traffic shaper. Nowhere does Ramamurthy 
disclose the need to include transmission delays in the characterization of the cell 
stream traffic or calculation of the UPC values. 

Estimating a mean delay using data indicative of a packet delay histogram, 
wherein data indicative of said packet delay histogram is a function of the delays 
experienced by data packets in transmission from the transmitter to the receiver 
and the number of data packets received at the receiver. Ramamurthy does not 
disclose it and does not inherently do it. It characterizes traffic based on mean and 
peak transmission rates. The determination of the UPC values does not include or 
depend upon the delays experienced by data packets in transmission from the 
source to the traffic shaper and, therefore, no packet delay histogram is used in the 
characterization of the cell stream traffic or calculation of the UPC values. 
Deriving a first variance or second variance from data indicative of a histogram or 
portions thereof. As discussed above, Ramamurthy does not disclose it and does 
not inherently need it. The determination of the UPC values does not include or 
depend upon the delays experienced by data packets in transmission from the 
source to the traffic shaper and, therefore, no packet delay histogram is used in the 
characterization of the cell stream traffic or calculation of the UPC values. 
Setting a delay equal to a function of the mean delay and the first variance and 
setting a buffer size equal to a function of the first and second variance. Again, 
Ramamurthy does not disclose it and does not inherently need it. The 
determination of the UPC values does not include or depend upon the delays 
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experienced by data packets in transmission from the source to the traffic shaper 
and, therefore, no packet delay histogram is used in the characterization of the cell 
stream traffic or calculation of the UPC values. 



In sum, none of Ramamurthy's cell stream traffic characterization steps, UPC value 
mapping steps, and renegotiation of UPC parameters with network providers steps use, are 
dependent upon, or otherwise employ data derived from delays experienced by data packets 
transmitted from the source to the Ramamurthy system. 
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